NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/m68k/304

Internet Message Format | 1996-08-05 | 5.8 KB

Path: bcarh8ab.bnr.ca!rpcook
From: [e-mail] (Richard Cook)
Newsgroups: comp.sys.m68k
Subject: Re: Help with setting up 68040 MMU req'd
Date: 29 Feb 1996 00:31:23 GMT
Organization: Bell-Northern Research Ltd.
Message-ID: <4h2s4r$[e-mail]>
References: <4h0i0s$[e-mail]>
NNTP-Posting-Host: bcarhd5a.bnr.ca
Keywords: 68040, 68030 MMU

In article <4h0i0s$[e-mail]>,
Kym Newbery <[e-mail]> wrote:
>
>    I am seeking somebody would can help me, or provide a pointer to
>information on how to setup the MMU in a home-grown 68040 processor board.
>I have read the 68040 users guide back-to-front and tried to understand the
>section on the MMU but there are no worked examples which makes understanding
>the MMU difficult.

I have implemented a 68060 MMU table and it is the same as the 68040.

>    What I would like to do is to write protect a block of SRAM.  The
>processor we have built has SRAM from address 0x02000000 to 0x021fffff (2Mega
>bytes, 512Klongwords worth).  I would like to be able to write data/code into
>the top section from 0x02100000 to 0x021fffff then turn on the MMU and write
>protect it.  I realise that I will need to create a translation table in RAM
>somewhere - the problem is how big a translation table do I require ??.. does
>it have to all the three levels of tables??, or can somebody describe what is
>required?  I'm a bit worried that we will have to create a huge translation
>table to implement a simple memory protection scheme.

Okay, first, you will need all three levels of the MMU tables, but you don't
need to fill in all the entries.  The root pointer(s) will point to the
first level table.  This table must be aligned on a 512 byte boundary and
each entry covers 32 Megs of your memory map.  There are 128 entries of 4
bytes each.  Initialize this all to zeros and fill in only those entries
that are applicable to your memory map (ROM, SRAM, I/O if you want) with
pointers to the second level table(s).

The least significant 2 bits of each entry, when set to zero, tells the
processor that this is an 'INVALID' entry and access to this address
range will generate a bus error.

The second level tables cover 256K each.  Again, these are 128 entry tables
of 4 bytes each, which must be aligned on a 512 byte boundary (simply put it
right after the first table).  Again, zero these tables and fill in only those
that you need with pointers to the third level tables.

The third level are 32 entry tables of 4 bytes each.  Well, they are if you
choose 8K coverage.  Your only other choice is 4K coverage, but I don't
remember the details for it.  If I remember correctly, each 3-rd level table
must be aligned on a 128 byte boundary.

These boundaries are required as the processor uses bits from the virtual (or
effective) address as an offset into the table(s).

So, excluding your ROM and I/O, the 2 Meg SRAM will require one top level
table (512 bytes), with the second entry pointing to the only second level
table.  The second level table will require 8 entries to point to 8 third
level tables (which can all be allocated right after the second level table).
These 8 entries will cover all of the 2 Meg SRAM.  You can set the
write-protection bits at this level on the last 4 entries to cover the 1 Meg
of program/data you mentioned.  The 8 third level tables will require 1K (8 *
32 entries * 4 bytes/entry) for a total of 2K for your MMU tables.

>
>    Also, we have implemented a hardware protection mechanism that asserts
>TEA when an access to non-allocated memory space is made (this then causes
>an access/bus error)  _and_ we would like to be able to cache the SRAM block
>but not our I/O block (which is located up near 0x0C400000 to 0x0C40FFFF).
>(I am using the TT registers to do this).

You may also use the MMU tables for caching the SRAM and cache-inhibiting the
I/O (I did).  You can use the TT registers to cover your ROM and/or I/O if you
like, (depends on design, frequency of turning on and off cache,
write-protection, whatever).

NOTE:  The manual recommends that you mark the MMU tables themselves, as cache
inhibited.  It is not required on the 68040, but manditory on the 68060 as the
processor by-passes the cache when doing an MMU table walk/search.

I tried having my MMU tables cover the data section and the transparent
translation registers cover the program section and part of my I/O.

This way I could change the write-protection on the program store all at once
by just changing one register (rather than updating many entries in the MMU
table).  Note, also that the TT registers cover memory starting on a 16 Meg
boundary (multiple?).  i.e. any one 16 Meg section, or a 32 Meg section
starting at 0, 32 Meg, 64 Meg, etc., or a 64 Meg section starting at 0, 64
Meg, 128 Meg, etc., etc., etc., ....   not too handy when you want to
cover a section, perhaps 1 Meg, in the SRAM.

Also, beware of using copyback cache mode with write-protected storage.
If you unprotect memory, write to it, then protect it again ... the data is in
the data cache with the dirty data bit on, it never went to the actual
storage.  When the cache is later flushed, or the cache line is reused, the
dirty data will, at that time, be written our to the now write protected
storage and, voila, a bus error!

The use of the TEA for your bus errors is required when the MMU is turned off
but should not be needed when using the MMU tables.  As soon as the processor
finds and 'invalid' entry in the MMU tables, it will generate an internal bus
error, so the address will not make it out to the data bus at all.

Good luck.  And if you find an algorithm for determining the instruction
length given an address in program storage, let me know ... I am working on a
bus error handler that needs it on the 68060.

--

Richard Cook          NOTE:  my e-mail id has changed!  (was [e-mail])
[phone]
[e-mail]      My opinions are not necessarily NORTEL / BNR's.